Skip to main content

Aventora Application Change Management Policy

FieldValue
Version1.0
Effective dateJuly 6, 2026
OwnerEngineering Leadership
Review cadenceAnnually, and upon material changes to release processes, hosting models, or product architecture

This document defines Aventora’s application change management requirements and describes operational practices used when modifying, testing, approving, and deploying Aventora software and related infrastructure configuration.

This policy supports enterprise security reviews. It is not a certification, attestation, or guarantee that every control is uniformly implemented in every environment. Managed cloud, customer self-hosted Docker, and private-cloud deployments may follow the same principles with deployment-specific variation.

1. Purpose​

The purpose of this Application Change Management Policy is to ensure application changes are implemented securely, consistently, and with minimal operational risk.

These practices apply across Aventora platforms—including Engagement Hub, Domain Assistant, Aventora CRM, administrative applications, mobile clients, and supporting infrastructure—and provide a common reference for engineering, operations, and customer security teams when evaluating how Aventora develops and releases software.

2. Scope​

This policy applies to changes affecting the following components across Aventora-managed and Aventora-supported deployments:

ComponentDescription
Web applicationsAdmin portal (aventora-admin), CRM web UI (twenty-front), marketing surfaces
APIsREST, GraphQL, WebSocket, and webhook endpoints exposed by Engagement Hub, Domain Assistant, CRM, and related services
AI servicesServer-side LLM and speech integrations configured for active sessions (for example, OpenAI, Groq)
Mobile applicationsAventora Hub mobile clients that consume platform APIs
Infrastructure configurationReverse proxy settings, TLS certificates, firewall rules, host OS configuration, and environment files on deployment hosts
Docker deploymentsDockerfiles, Docker Compose stacks, container image builds, and image promotion to production hosts

Customer-managed systems outside Aventora’s direct control remain the customer’s responsibility unless explicitly covered by a services agreement.

For the full secure development lifecycle policy, see Secure Development Lifecycle (SDLC) Policy. For API-specific secure development requirements, see API Security Policy.

3. Roles and Responsibilities​

Engineering Leadership​

  • Owns this policy and approves material updates
  • Approves production deployments and high-risk changes
  • Defines security and quality expectations for release promotion
  • Conducts the annual review of this document
  • Approves new third-party integrations and material architecture changes before production use

Developers​

  • Implement changes in version-controlled source repositories
  • Use feature branches where appropriate for non-trivial work
  • Submit changes for peer review before merge to shared branches
  • Run applicable tests, pre-deploy checks, and security scan utilities before requesting production promotion
  • Document environment variable, configuration, and migration changes that affect deployments
  • Avoid committing secrets or live credentials to source control

DevOps / System Administrators​

  • Build, tag, and promote Docker images according to release procedures
  • Apply infrastructure and Compose configuration changes on production and staging hosts
  • Restrict production host and environment-file access to authorized personnel
  • Execute controlled rollouts and rollbacks using versioned container images
  • Maintain deployment runbooks and coordinate emergency changes
  • Apply operating system and container base-image updates as part of routine maintenance

4. Change Classification​

Aventora classifies changes to determine the appropriate review depth, testing expectations, and approval path.

ClassificationDescriptionTypical examples
StandardRoutine application or configuration updates with established release proceduresBug fixes, UI improvements, dependency updates, non-breaking API additions
EmergencyUrgent changes required to restore service, mitigate active security risk, or address production incidentsSecret rotation after suspected compromise, blocking malicious traffic, critical hotfix for outage
SecurityChanges to authentication, authorization, secrets handling, webhook validation, encryption, or other security-sensitive behaviorNew public endpoints, auth model changes, CORS policy updates, API key scoping changes
InfrastructureChanges to hosting, networking, TLS, reverse proxy, database connectivity, or Docker host configurationNew VPS deployment, certificate renewal, Compose stack updates, firewall rule changes
ConfigurationRuntime setting changes that do not require application code modificationEnvironment variable updates, feature flags, provider API version pins, rate-limit tuning

Security and infrastructure changes generally require additional review before production application. Emergency changes may bypass normal lead time but require post-implementation review and documentation.

5. Development Requirements​

Version control​

  • GitHub version control — Aventora product source code is maintained in private GitHub organization repositories. MFA is required for all personnel with repository access.
  • Feature branches where appropriate — Engineers use feature branches for non-trivial changes and merge to shared integration branches (for example, main) through pull requests or equivalent review workflows.
  • Traceability — Commits, pull requests, and merge history in GitHub provide an auditable record of what changed, when, and by whom.

Secure code review​

  • Peer review before merge — Material code changes are reviewed by engineering personnel other than the author before merge to shared branches. Reviewers evaluate correctness, security impact, and compatibility with existing authentication, authorization, and data-handling patterns.
  • Security-focused review — Changes affecting authentication, authorization, public endpoints, webhook handlers, secrets, cross-service trust boundaries, or customer data handling receive explicit security consideration during review.

Automated security checks​

  • Repository security scan utilities — Aventora maintains manual security scan tooling for core platform repositories (Domain Assistant, Engagement Hub, and the admin dashboard). These utilities perform static analysis including dependency audit, secret detection, SAST (where applicable), and custom configuration checks. Optional live probes support auth regression, webhook abuse, and CORS validation against dev or staging instances.
  • Pre-deploy validation — Engagement Hub runs preflight checks (Python compilation and smoke imports of critical startup modules) before production service restarts.
  • Honest scope note — Security scans and pre-deploy checks are engineer-initiated before release promotion. Continuous automated enforcement of all scan types in CI on every pull request is an ongoing improvement area; see Vulnerability Management.

Dependency review​

  • Dependency manifests (requirements.txt, package.json, and equivalent) are updated through version-controlled changes.
  • Security scan utilities run dependency audits (pip-audit for Python services, npm audit for Node-based applications) and report findings by severity.
  • High-severity dependency vulnerabilities identified before release are remediated or documented with an approved remediation plan before production promotion where scans are executed.

6. Testing​

Testing expectations vary by product and change type. The following practices apply across Aventora engineering.

Functional testing​

  • Developers validate changed behavior locally or in shared development environments before merge.
  • CRM and related monorepo components support unit test targets (for example, npx nx test for applicable packages).
  • Manual functional verification is performed for user-facing workflows, telephony paths, and administrative operations affected by the change.

Integration testing​

  • Cross-service integrations (Hub ↔ Domain Assistant, CRM ↔ Hub engagement flows, webhook receivers, OAuth callbacks) are validated in non-production environments where available.
  • CRM maintains integration test targets that exercise database-backed workflows where implemented.
  • Database schema changes use migration tooling rather than manual ad hoc production changes.

Security validation​

  • Security scan utilities are run before production promotion for material releases affecting core platform repositories.
  • Findings at high severity or above are remediated before release where scans are executed, or documented with Engineering Leadership approval and compensating controls.
  • Live security probes run against localhost or explicitly confirmed staging targets following documented safety rules.

Non-production validation before release​

  • Changes are validated in development or staging environments where applicable before production promotion. Aventora operates staging and test endpoints for selected managed services (for example, test Hub environments); not every product has a dedicated long-lived staging stack in every deployment model.
  • Customer self-hosted deployments may validate against local or customer-provided non-production instances before applying updates to production Compose stacks.

7. Approval​

Production deployment approval​

  • Engineering Leadership approval — Production deployments for Aventora-managed environments require authorization from Engineering Leadership or designated engineering leads responsible for the affected product.
  • High-risk changes receive additional review — Security, infrastructure, and changes affecting authentication models, public API surfaces, data retention, or third-party integrations receive additional review before production application. New vendor integrations require Engineering Leadership approval before production use.

Customer-managed deployments​

  • Customer self-hosted and private-cloud deployments follow the same version-controlled release artifacts and documented procedures; the customer or their operations team executes deployment on their infrastructure using Aventora-provided images, Compose files, and runbooks.

8. Deployment​

Aventora products are deployed primarily as Docker-based containerized services.

Docker-based deployments​

  • Application services run in Docker containers orchestrated with Docker Compose on Linux hosts (Ubuntu LTS in standard deployment documentation).
  • Reverse proxies (Nginx or Caddy) terminate TLS and forward traffic to application containers.
  • Runtime secrets and configuration are supplied via host-managed environment files and Compose env_file injection—not baked into image layers.

Version-controlled releases​

  • Application code, Dockerfiles, Compose definitions, deployment scripts, and configuration templates are stored in version control.
  • Production images use versioned tags (for example, date-based or semantic release tags). CRM supports build-and-push workflows to container registries with explicit tag promotion on deployment hosts.
  • Running containers are replaced with new image versions rather than modified in place.

Controlled rollout​

  • Deployments are executed according to product runbooks provided to customers under agreement.
  • Preflight and security checks are completed before production service restarts where applicable.
  • Compose health checks and restart policies support service availability during container replacement.

Rollback capability​

  • Previous image tags remain available for rollback. Operators can redeploy a prior tagged image (docker compose pull with a previous tag, or local image retention) and restart the stack.
  • Configuration rollback uses version-controlled Compose files and documented environment settings restored from Git history or host backups where maintained.
  • Database migrations are planned with backward-compatibility considerations; emergency rollback may require Engineering Leadership guidance when schema changes are involved.

9. Emergency Changes​

Emergency changes are permitted when necessary to restore service, contain an active security incident, or mitigate imminent operational risk.

Expedited deployment​

  • Emergency changes may be applied immediately without waiting for standard release lead time.
  • Examples include secret rotation after suspected compromise, blocking malicious traffic, and critical production hotfixes during outages.
  • Authorized DevOps or Engineering Leadership personnel may apply urgent configuration or deployment changes directly on production hosts.

Post-implementation requirements​

  • Post-implementation review — Emergency changes are reviewed after application to confirm effectiveness and identify follow-up remediation.
  • Documentation — The change is documented afterward, including what changed, who authorized it, when it was applied, and any residual risk or follow-up tasks.
  • Backport to version control — Code or configuration changes made directly in production are backported to GitHub repositories as soon as practicable to restore single-source-of-truth traceability.

For related incident handling expectations, see Incident Response.

10. Auditability​

Aventora maintains change traceability through the following mechanisms:

MechanismDescription
GitHub historyCommits, branches, pull requests, and merge records provide an auditable history of source code and infrastructure-as-code changes
Deployment historyVersioned container image tags, Compose deployment commands, and operational runbooks document what was deployed and when
Security findingsSecurity scan reports (stored locally in reports/security/ when generated) document findings, severity, and remediation status for releases where scans are executed
Application and system logsOperational logs on hosts and within services support post-deployment verification and incident investigation; see Logging and Audit

Aventora does not currently maintain a centralized change-management ticketing system or immutable change ledger across all products. Traceability relies primarily on GitHub, deployment artifacts, and operational records.

11. Review​

This Application Change Management Policy is:

  • Reviewed annually by Engineering Leadership, and upon material changes to release processes, hosting providers, product architecture, or subprocessors
  • Owned by Engineering Leadership, which approves updates and communicates significant changes to engineering and operations teams

Questions regarding this policy, deployment-specific change procedures, or security questionnaires may be directed to security@aventora.ai.

Alignment with industry guidance​

This policy addresses control themes commonly evaluated in enterprise security programs without asserting formal certification:

GuidanceRelationship
SOC 2Change management, secure development, and deployment authorization themes are reflected in the practices described here and in related security documentation
ISO 27001 principlesControlled change, segregation of environments, and traceability align with common ISMS expectations; a formal ISMS is not claimed
OWASPSecure development and pre-release security validation align with OWASP software assurance guidance

For control theme alignment, see Compliance.

Changelog​

DateChange
2026-07-27Linked Information Security Risk Management Policy.
2026-07-20Linked Secure Development Lifecycle (SDLC) Policy.
2026-07-06Security contact updated to security@aventora.ai for policy inquiries.
2026-07-06Initial publication of Aventora Application Change Management Policy v1.0.